<body>
<h1>Re·Mote Testbed Framework Java Library</h1>
<p>

This library consists of a set of packages that provides
APIs that can be used by clients for connecting to testbeds
using the
<a href="http://remote-testbed.googlecode.com">Re·Mote Testbed Framework</a>.
In the following, an overview of the various design decisions are presented.

</p>

<h2> Library Structure </h2>
<p>

</p>

<h2> Versioned APIs </h2>
<p>

To support future updates to the APIs, most importantly services
that involve the communication with the testbed server, the library
and API is versioned in such a way that it will be easier to update
a service provider to support the changes.
		Do	
</p>

<h2> Mote Information and Control </h2>
<p>

The most important function of this library is the API
provided for mote control. The rest is more or less just
a mean to achieve this.

For certain mote operations an authenticated session is
required.

</p>

<h2> Session Management </h2>
<p>
All operations happens withint the context of a session.
Most of this is hidden in the mote control interfaces,
however, any implementation needs to keep track of this
relation "behind the scene".
</p>

<h2> Service Management </h2>
<p>

One service per sub-package?

- Services are modelled on the services of remote-1.x
  and the way in which the remote-1.x client works.

</p>

<h2> Asynchronous vs. Blocking APIs </h2>
<p>

The APIs of this library is designed to support as many different
work-flows as possible. This means that both blocking and asynchronous,
web-based etc. Axis supports asynchronous and AJAX web applications (GWT)
are inherently asynchronous.

Two concepts are used:

- Listeners: One listner pr. object, one completion event/method per call.
	
- Callbacks: One callback handler per call/method.

</p>

<h2> Abstraction layers and types </h2>
<p>

Layering means that some types will be represented at different layers
from codes exchanged over the network protocols to values exposed to
the high-level mote control command results.

</p>

</body>
